My existing iOS app has a legacy App ID prefix which does not match my Team ID. I am planning on migrating it to my Team ID. I am aware of the potential issues with keychain access groups, however I wanted to double check that there are no issues related to "Sign in with Apple". My app is currently the "Primary App ID" in the "Sign in with Apple" settings. The full App ID is listed there, including the prefix. Can someone from the relevant team at Apple confirm that changing the App ID prefix to Team ID has no effect related to "Sign in with Apple"?

My iOS version of the app is available on the App Store with a non-team ID prefix for its bundle ID. It has been available there for a long time and I am not sure why I chose a custom prefix for it. The Mac version of the same app is available on the Mac App Store with a different bundle ID and with a prefix that matches my team ID. I am currently looking to "merge" both apps into a single bundle ID. The plan is to stop using the current Mac app and release a new one as a universal app under the existing bundle ID for the iOS app. Unfortunately, it looks like that the Mac App Store does not actually allow any submissions that have a non-team ID for a prefix. I know that it is a very specific case but any suggestions would be welcomed.

If you have a Siri phrase for an app Intent: phrases: ["Show me my books on \(.applicationName)"] What is the right format to localize that phrase in a strings file? genstrings does not work for that phrase. I assumed that it would be: "Show me my books on ${applicationName}" = "Show me my books on ${applicationName}"; But that does not work.

I have started implementing support for the new App Store Server notifications (version 2): https://developer.apple.com/documentation/appstoreservernotifications/receiving_app_store_server_notifications I am not sure how to prevent a possible mad-in-the-middle attack when using those notifications. The decoded header that I get for notifications in the Sandbox environment is missing the "kid" field that is used to identify the key used to generate a signature. Yes, I understand the the whole entire certificate chain is available in the "x5c" field and it could be verified by itself. However, this does not guarantee that a notification was signed by Apple. This approach (with no specific key, with a certificate chain in x5c) works fine when verifying a receipt on device with StoreKit 2 but it does not work when getting a notification on a server.

I am trying to submit an app from Xcode 13 beta 1 to App Store Connect for internal TestFlight testing. After submission my binary is marked as invalid and I get the following email: ITMS-90338: Non-public API usage - The app contains or inherits from non-public classes in AppClips/App Clip.app/App Clip: NSConstantArray ,The app contains or inherits from non-public classes in Watch/WatchOS App.app/PlugIns/WatchOS Extension.appex/WatchOS Extension: NSConstantArray, NSConstantIntegerNumber  Uploading the same app from Xcode 12 results in a successful submission. Feedback FB9157492. Anyone else with the same problem?

Has anyone tried creating a widget with WidgetKit for macOS Big Sur? I mean a widget for a Mac app. WidgetKit simulator crashes when I try debugging my widget. Same happens when I try running a widget with a new project in Xcode (FB8126474).

I have noticed a strange problem today. I have uploaded a build of my app to TestFlight for internal testing using Xcode 12 beta 3. The app has widgets and if I run the app locally from Xcode widgets are working on device. However, when I install a beta from TestFlight the widgets are not suggested by iOS and I can see in the logs that the widgets are actually crashing (something is going on with WidgetKit in the crash logs). This has started only with beta 3, I have previously used TestFlight with widgets in beta 1 and beta 2. Does anyone else have this problem? My feedback number is FB8122742.

Xcode 12 beta 3 has the following change: Interface Builder now supports the two-column and three-column styles for UISplitViewController introduced in iOS 14. (57025285) Which is great is you want to adopt the new Split View Controller API added in iOS 14. However, if you need to support iOS 13 for the time being, it might be easier to keep using the old API instead. And it looks like since Xcode 12 beta 3, there is no easy way to do that if you use Storyboards. Any UISplitViewController created with a Storyboard will use either a two column or a triple column style. And because of that there will be significant change in behaviour, new delegate callbacks will be used, etc. The only workaround that I found so war is to create a UISplitViewController manually, this way it gets the legacy style (UISplitViewControllerStyleUnspecified) and the classic API is used. Does anyone have a better solution?